I doubt that Lfs is D3D9, as far as I know it is D3D8, so you would have to put a wrapper d3d8.dll into the LfS directory. Of course this would work in case of Lfs without any problem, other developers already did with success.

If you follow the link from Stuff then you will also find a proxy.dll so that you do not need to write your own wrapper dll, but just load the proxy dll, that will connect to the wrapper dll (look for GPP). There is an API, where you can call functions inside the proxy dll.

Nevertheless I see some issues with this solution:

Reliability: if every developer is writing his own wrapper dll and going to put it into the Lfs folder then they will overwrite the wrapper dlls of other addons (keep in mind, that every wrapper dll has to use the filename d3d8.dll)

Stability: the wrapper dll is running in the process of Lfs. So if there is a bug in the wrapper dll, then it would have impact on Lfs too.

It is of course an interesting possibility for addon developers. And for my LfS TV director tool I would need to add some output too (later), but atm I am still not sure about the way to go. If there is no other simple possibilty (maybe Scawen would implement an API), then I would need to use this solution too.

Quote from Frankmd :

Would it be possible to make the camerapositioning work on the custom camera's too? Right now this camera can be rotated, pitched and rolled, but not translated. I guess only my own tool and LFS TV Director would benefit from this, but it would really add a lot more realism and possibilities for streams etc.

1) I totally agree. I would like to use different car cams so I would have to control the position relative to the car too. (priority high)

2) Additionally a pit stop packet for LfS TV director too. (priority low)
Requirement: ideally at the moment when the car enters the pit lane.
Required information:
- Unique ID
Desired information:
- reason (drive through, stop n go, or pit stop)
- estimated time of pit stop

sometimes when I try to set a camera postion with a CPP packet I get this error message. I assume, the position is outside the drivable area and therefore invalid. Thats why I capture a valid position with a SCP packet. I store the values from the answer packet and use them later in my CPP packet. I tought to prevent this "Follower could not find position" issue in this way.

Wrong. It still happens. In most cases it happens if the camera position is near the bounds of the drivable area. What can I do to make my application more user friendly and to prevent this message?

My current project (LfS TV director) is using pth files. May I put these files into my distribution? Or do I need to get permission to do so? Or should I write something (and what) into the credits? I have looked into the readme of LfS Spectator and have not found any comments regarding the pth files or about the source of the pth files.

regards

Sören

Quote from duke_toaster :

[SHAMELESS BEGGING]Johnathan Russ at OLFSLTV and a new project involving me and some other people have a dinky little app request.

We're not looking for anything silly, we're just looking for an autodirector. It doesn't need to work in shift-U - all it needs to do is just basically find the action and go to that LFS TV camera. If it can go to the custom cameras of the dude running it, great, if not, we don't care.[/SHAMELESS BEGGING]

hello Duke,

look here for the LfS TV director. With this project I have started programming exactly such a tool. Currently it is still proof of concept but I am improving it consecutively. The next version will support all tracks and a possibility to place your own camera positions. I will add camera files for at least the aston tracks, and add more files in later versions. I also considered about the current LfS TV cameras (not shift-U mode) but there are some issues I would have to find solutions for. That's why I am working in shift-U mode, so I have complete control over camera switsches.

regards
Sören

Quote from Fischfix :

i don't think there will be any news on this project. soeren was last time online racing with lfs october 6th 2006. i wrote several emails and PMs to him, but did not get an answer so far


looks like the great tool is dead. the alternative noobTV will not have an action-detection in it so, i think the only possibility is if someone makes this tool from scratch...


not me

No hurry, please. Keep patience. I am still working on it.

I started to make camera files for the other tracks, but ....ops... there are more than 40 configurations...
So I have changed the GUI and implemented a possiblity to edit the camera files in a most comfortable way (at least I hope so).
Currently I have to rewrite the whole source code (the current code was written quick and dirty, in a very bad programming style) to get a solid basis for further improvement.
And hey... I have a wife, 2 children and a full time job as a head of department. So please excuse for the slow progress.

Because of the slow progress I plan to release the current version as a first stage without further improvement, but with at least the camera files for the aston tracks. Further versions with further improvement and more track camera files may follow. Usually I would not do it this way, but I see that progress is much too slow, and I do not want you to be waiting too long.

regards
Sören

@Fischfix: keep care with your statements.

BTW:The reason why I was not racing Lfs so long is, that I am a GPL driver. But I love the idea of correct simulated physics, force feedback, sound, etc..., so I love Lfs. And in GPL a director application would be much more difficult to implement, so thanks to Scawen for this ingenious insim API.

Quote from Leifde :

Sorry to bump and old(ish) thread but are you still working on this Soeren?

no problem, and yes, I am still working on this project. Unfortunately I do not have much time, only some hours every weekend. I hope to be able to make some good progress end of december, when I have some days holiday.

regards

I have made some tests. It seems that this issue does apply to multiplayer only. I have tested with singelplayer replays and there the lap number always increased after the car crossed the node of the finish line. Maybe it is an latency or lag related issue?

Quote from Dygear :

Assumeing that your getting the race from the start, ....

this is a very limiting assumption, isn't it?
Well, it is not really a big problem to handle (see below code snippet). But what I am actually wondering about is, if it is intentionally, otherwise it would have been declared as a bug.

the way I would handle this:

Hello,

Thanks for all your suggestions. Now some statements about things I plan to do in the future:
- Of course camera positions will not be hardcoded in the final version. This was only done for test purposes, because I still have not yet code to read a camera config file.
- I am still not satisfied with camera movement. Especially with the fast cars it looks much too nervously.
- Fight focus instead of car focus: of course, I plan to do.
- manual interface to override carfocus: The App will get a nice GUI to let you decide what cars to focus and to override the automatic focus. This will be useful for real time broadcasts where a moderator is commenting the race.
- Show the leader at least sometimes. Currently the algorithm is too simple, it is based only on distance between cars. Unfortunately the leader has no car ahead, so he gets not enough importance calculated to get the focus.
- Better event detection: I will try to detect spinning cars, off track situations and pit stops. I hope I will find solutions for proper detection.

Regards
Soeren

Quote from nutty boy :

How do i get back to the original shiftU layout after i've typed in the insim. I'm now stuck with the director.

from the documentation insim.txt, there is the following description:

"You can shut down InSim completely and stop it listening at all by typing in
/insim=0 into the connected LFS."

Quote :

it says type command line [...] where do i do that? i'd like to try it out.
Thanks

It would also be possible to start lfs and press button "t" to type a chat message and then write "/insim=32300" (without the ") into the chat message. After doing this you should see a "hello lfs..." message.

hello community,

everyone was asking for onboard cameras... here they are.

with kind regards
Soeren Scharf


History:

24.05.2008, Version 0.3:
- custom cams (onboard, front and rear cam) added
- added option to disable overlay output (driver info, race time/laps, standings...)
- added alias file for driver names
- fixed bug: tvdirector did not save cam files, when changes were made in GUI
- fixed bug: handling of driver change (IS_TOC)

27.12.2007, Version 0.2:
- insim support for Patch X and later
- devided the application into 2 separate executables (GUI and Control)
- GUI lets you control cameras manually (useful for professional broadcasters)
- action detection completely rewritten (still based only on distance but in a much smarter way)
- output of standings, driver information and lapcount or left racetime

14.03.2007, Version 0.1:
- new GUI
- handle all tracks
- insim port configurable
- possibility to connect to a remote LFS
- frontend to create/modify cam files
-

22.10.2006, Version 0.0 (Demo):
- first test version
- just a study to test feasibility
- worked only with BL1
- all values hardcoded
.........................................................

Last edited by Soeren Scharf, Sat, 24 May 2008 20:54.

hello,

I wonder about the lap number in the MCI packet. I have observed that the lap number increases very often shortly before the car crossed the node of the finish line. I.e. in blackwood the node of the finish line is node 431, but I found the lap number already increased when the car is still in node 427, 428 or something else lower than 431. I have attached a log file with items every time a car crossed s/f detected by a change of the lap number in the MCI packet.

This is an issue for me, because I would need to track the lap number myself instead of just reading it out of the MCI packet. Are there solutions? Or am I just wrong?

Regards
Soeren

thanks for the hint, Scawen. After reading the description of the PTH files, I understand how nodes are used to construct a track. So a node is not a section of a track but a node is the line where 2 sections are concatenated.

A picture is more meaningful that thousands of words, the bold black line is one of our nodes.

really helpful, indeed. and now would you please answer my question? i.e. what about the length of a "node"?

what is the exact meaning of the term node in the insim packets? I is just a short section of the track? Is the length of all nodes (and maybe the nodes of all tracks) equal?

Is there a glossary available with a description of all terms, so developers can save time and focus on programming instead of doing a lot of "try and error"?